Subject: APPN DLUR Architecture Reference Version 1.2 available

From: "Ed Tremblay (254-5515)" <[email-masked]>
Date: Thu, 7 Dec 95 17:14:28 EST

The APPN DLUR Architecture Reference, Version 1.2, has been updated and
is available by anonymous FTP to networking.raleigh.ibm.com (also known
as networking.cary.ibm.com and ibmstandards.cary.ibm.com) under the
name of aiw/dlur/dlur8.psbin - the file is a PostScript file, but treat
it as binary when you get it and print it.  There are also compressed
versions of the file (aiw/dlur/dlur8.zipbin and aiw/dlur/dlur8.exebin)
as well as a BookManager version (aiw/dlur/dlur8.bookbin).

There is a new document number, SV40-1010-01, associated with the
APPN DLUR Architecture Reference (I've also included the original
document numbering scheme, now up to DLUR-8, on the inside cover).  The
BookManager version of this document will be included in the "IBM
Networking Systems Softcopy Collection Kit" CD-ROM in mid-1996.

The items added in Version 1.2 are:

** 1) changed Token-Ring signalling information to use non-canonical
      encodings

      During the APPN Reference SIG at AIW6, a clarification
      entitled "Encoding MAC address on TG Descriptor" was discussed.
      This item describes the use of non-canonical (MSB) encoding for
      a Token-Ring MAC address.  This conflicts with the DLC signalling
      information formats for Token-Ring in CVs X'4693' through '4696',
      which require canonical (LSB) encoding for Token-Ring MAC and SAP
      addresses.

      The approach to correct this conflict, agreed to by a concensus
      of the SIG, is to change the DLC signalling information formats
      to use non-canonical encodings for Token-Ring MAC and SAP
      addresses only.  This change will impact the Token-Ring
      definitions of CVs X'4693' (destination SAP), X'4694'
      (destination MAC), X'4695' (source SAP), and X'4696' (source MAC).

      This item was documented in abs8229.txt and arch8229d.psbin

** 2) added XID1 support to DLUR/S

      The DLUR Architecture Reference (section 13.1.1.1) explicitly
      lists XID0 and XID3 as supported, while other sections, including
      the GDS X'1500' CV X'81' format, just say "XID image".

      The question of XID1 support has been raised.  The intent was not
      to leave XID1 support out of DLUR/S.  However, DLUS only
      implemented XID0 and XID3 support.  It is possible that some DLUR
      implementations may have done so too.

      To correct this omission, XID1 will be added to section 13.1.1.1
      as well as the XID format section in appendix C.

      VTAM has agreed to APAR XID1 support into its DLUS implementation.
      If DLUR implementations take any received XID and forward it to
      the DLUS regardless of XID format type, they will work without
      change.  Any DLUR implementation rejecting a received XID1 should
      change its implementation to accept and forward it.

      This item was documented in abs8256.txt and arch8256d.psbin

** 3) corrected sense data encoding in DLUR protocol error alert

      Review comments of the APPN DLUR Architecture Reference Version
      1.1 from Data Connection Ltd. and IBM include the following:

         One of the sense data values used in APPN/DLUR Alert CPDL001
         is listed in section 4.6.1.1 as X'1001 0001' but in the
         previous section is listed as X'1001 0000'.  We believe that
         X'1001 0000' is correct.

      To correct this error, X'1001 0001' will be replaced with
      X'1001 0000' in APPN/DLUR Alert CPDL001.

      This item was documented in abs8257.txt and arch8257d.psbin

** 4) corrected actions encoding and ordering in DLUR configuration
      error alerts

      Review comments of the APPN DLUR Architecture Reference Version
      1.1 from Data Connection Ltd. include the following:

         In the Actions for APPN/DLUR Alert CPDL002, the text states
         "Correct installation problem" with a coding of X'5100'.
         When testing with Netview, we found that it didn't recognize
         this code.  In looking at Formats, X'1500' corresponds to
         "Correct installation problem".

      To correct this error, X'5100' will be replaced with X'1500' in
      APPN/DLUR Alerts CPDL002, CPDL003, CPDL004, and CPDL005.

      Shortly thereafter, DLUR testing discovered an additional concern:

         In the MS Reference-style Alert tables, you're supposed to
         list the Recommended Actions for each of the User, Install,
         and Failure Causes groups right after that group.  This is how
         the tables indicate whether the Recommended Actions belong in
         the X'94', X'95', or X'96' SV.

         This problem occurs in all four of the configuration error
         Alerts.  Currently the tables read:

               User Causes       (none)
               Install Causes    <<various code points>>
               Failure Causes    (none)
               Actions (note 1)  X'1500'

         They should read:

               User Causes       (none)
               Install Causes    <<various code points>>
               Actions (note 1)  X'1500'
               Failure Causes    (none)

      To correct this error, the order of the Failure Causes and Actions
      will be swapped in APPN/DLUR Alerts CPDL002, CPDL003, CPDL004,
      and CPDL005.

      This item was documented in abs8258.txt and arch8258d.psbin

** 5) further clarified DLUR processing of short RSP(BIND) RUs

      Review of AIW item 8218 discovered a problem in the description
      of setting the RSP(BIND) pacing fields when constructing a short
      RSP(BIND).

      The pacing fields are supposed to be set for the REX (SLU) stage,
      but the current description details the process for setting the
      APPN (PLU) stage.

      To correct this, the DLUR architecture reference section on
      setting the pacing fields in "short RSP (BIND) processing" has
      been replaced with the following:

         - setting the pacing fields in the RSP(BIND) for the REX stage
           to the BIND request values

      Subsequent processing (actually the section that's currently in
      the document about setting the pacing values for the PLU stage)
      will take the REX stage values and change them to the PLU stage
      values.

      This item was documented in abs8259.txt and arch8259d.psbin

** 6) added DLUR processing of Whole BIUs Required Indicator (WBRI)

      Christine Martin of Data Connection Ltd. asked whether the WBRI
      setting in an extended short RSP(BIND) should not reflect the
      segment reassembly support of the DLUR.

      The problem statement is as follows:

         I've got a quick question about the recent clarification to
         the DLUR architecture for extending short positive response
         BINDs.  The clarification states that converting the short
         +RSP(BIND) into an extended short form RSP(BIND) includes:

            - setting the whole-BIUs required indicator on if the
              RSP(BIND) will be reextended.

         From looking at formats, setting this bit on (1) means that the
         sending node doesn't support receipt of segments on this
         session.  Shouldn't this be set off (0) indicating that the
         sending node supports receipt of segments on this session?
         (I notice that the formats state that the bit is reserved for
         non-extended, non-LU 6.2 BINDs - so again, wouldn't it be set
         to 0?)

      The current description was derived from the NCP BF
      implementation.  It turns out that NCP always sets WBRI on
      because NCP never reassembles segments at its BF.  However, a
      DLUR BF should have as an implementation option segment reassembly
      support and should then set the WBRI according to its own segment
      reassembly capabilities.  This could be done both on RSP(BIND)s
      built by the DLUR as well as received by the DLUR.

      What needs clarification in DLUR architecture is how to set WBRI
      based on DLUR's capabilities.

      The clarification replaces the WBRI section in "short RSP(BIND)
      processing" in the DLUR architecture reference with a new section
      on "WBRI processing" within the RSP(BIND) section; it includes
      the following:

         * WBRI processing - a DLUR can, as an implementation option,
           support segment reassembly at its BF; whether or not a DLUR
           provides this support is reflected in how it sets the Whole
           BIUs Required Indicator (WBRI) - WBRI=0 means sending node
           supports receipt of segments on this session while WBRI=1
           means sending node does not support receipt of segments
           (this processing could apply to RSP(BIND)s built as well as
           received by the DLUR):

              - if WBRI is valid (not a reserved field), use the
                received value
              - if WBRI is reserved, act as if DLUR received WBRI=1
              - if WBRI=1 and DLUR BF can support segment reassembly,
                set WBRI to 0
              - if WBRI=1 and DLUR BF can't support segment reassembly,
                set WBRI to 1;

      This item was documented in abs8259.txt and arch8259d.psbin

** 7) added DLUR processing of extended UNBIND RUs

      DLUR testing uncovered a condition not described in the
      architecture, specifically how the DLUR BF should process
      extended UNBIND RUs when the dependent LU can only handle
      unextended UNBINDs.

      The problem statement is as follows:

         I've run across a problem with "extended" UNBINDS.
         When we receive a Bind for a DLuR LU we unextend it,
         send it to the LU, then extend the ensuing +rsp(Bind).
         Since we've accepted an extended Bind, Vtam will send an
         "extended" Unbind.  Currently, there is no code to
         unextend Unbinds and so the Unbind is sent as is to the LU.
         The LU however is ( for some reason ) checking the length of
         the RU, and since it never expects Unbinds longer than 6 bytes,
         it rejects the RU and brings down the session.  In most cases
         we're taking down the session anyway, but not in the case of a
         NetView logon. NetView sends an "UNbind with a bind forthcoming
         type of Unbind.  Since the LU is bringing down the session, the
         "forthcoming Bind" is also rejected.
         So, do we need to add code in the DLuR to "unextend" Unbinds??
         or Is this a bug in the LU code for not accepting the Unbind
         and just ignoring the extra data (CV60) ??

      NCP BF takes an extended UNBIND and unextends it when necessary.

      What needs clarification in DLUR architecture is when and how to
      convert an extended UNBIND into an unextended UNBIND.

      The clarification updates the DLUR architecture reference section
      on "LU-LU Session Deactivation" with the following:

         The UNBIND will be unextended if necessary, based on the
         extended BIND support indicators in the CV X'0C' in the
         +RSP(ACTLU) - this involves:

             * all UNBIND types except X'FE' - truncating the UNBIND
               RU to only the request code plus the UNBIND type;

             * UNBIND type X'FE' - truncating the UNBIND RU to only the
               request code, the UNBIND type, and the sense data.

         No reextending of the RSP(UNBIND) is required.

      This item was documented in abs8259.txt and arch8259d.psbin

** 8) retired subfield X'95' on CV X'46' for SDLC SW and SDLC NS

      This item covers the retirement of subfield X'95' on CV X'46'
      for SDLC switched and SDLC nonswitched.  This subfield was
      published in the DLUR architecture to convey SDLC station role,
      but this is not needed for DLUR since the DLUR station role is
      always primary.  No other need is seen for this information.

      This item was discussed and approved at AIW7; the changes can be
      seen in arch8318d.psbin

** 9) changed FR to FRPVC

      This item covers the change of names used in the DLC type field
      carried by CV X'4691'.  Frame-relay permanent virtual circuit is
      changed from FR to FRPVC and FR is retired.

      This item was discussed and approved at AIW7; the changes can be
      seen in arch8318d.psbin

** 10) changed wording for DLC types V25 and V25BIS in CV X'4693 & 4694'

      This item covers changes in the wording of the description of
      subfields X'93' and X'94', as carried by CV X'46' for V.25 and
      V.25bis.  In addition to clarifying several points, a restriction
      on the number of dial digits is loosened.

      This item was discussed and approved at AIW7; the changes can be
      seen in arch8318d.psbin

** 11) added APPN X.25 PVC and SVC signaling information formats

      This item covers the addition of signaling information for X.25
      permanent virtual circuits (PVCs) and switched virtual circuits
      (SVCs) using new Extended Signaling Subfields X'91' through
      X'F0' for connection from a DLUR to downstream PUs.

      This item was discussed and approved at AIW7 with changes
      electronically approved after the meeting documented in
      arch8304d.psbin

** 12) added DLUR processing to send PU name to DLUS

      Requirements from several vendors have been submitted to allow
      the DLUR to send a PU name to the DLUS to be used there.  Multiple
      reasons have been provided also, for example, to allow the end
      user to provide a PU name instead of the DLUS-generated name when
      the PU is dynamically created at the DLUS; and to provide the DLUS
      with additional PU search criteria when the DLUR and DLUS are
      adjacent and two PUs have been defined at the DLUS.

      The solution is to add CV X'0E' type X'F1' (PU name) to the FID2
      Encapsulation (X'1500') GDS variable when it encapsulates the
      REQACTPU RU to allow the DLUR to send the PU name to the DLUS
      (just as currently the DLUS uses the same CV on ACTPU to send the
      PU name to the DLUR).

      The PU name can be sent either with or without a NETID:

        * non-network qualified (without NETID) - in this case the DLUS
          will match only on PU name.

        * network qualified (with NETID) - in this case the DLUS will
          match on NETID.PUname.  It is an implementation option for
          the DLUR to choose how to get the PU name and the NETID to
          put together a network-qualified PU name to put in the CV
          X'0E'.  The DLUR could require the user to define a
          network-qualified PU name, or only define a PU name and use
          its own NETID, or in the case of a downstream PU learn about
          the NETID via XID (remember: a downstream PU could have a
          NETID different from the DLUR's NETID; it is the PU's NETID
          which will be included in the CV X'0E').

      In adding this function,

         - the DLUR will optionally include the PU name when sending a
           REQACTPU; it can send

              * PU name

              * PU name, XID

              * PU name, signalling information

              * PU name, XID, signalling information

              * XID

              * signalling information

              * XID, signalling information

           When both PU name and CP name are sent to the DLUS, these
           names must be different.

         - any signalling information received at the DLUS will be
           used for (in addition to PU correlation for internal PU)

              * network management

              * CSX user exit for connection verification and accounting

         - the DLUS will look for CV X'0E' upon receiving a REQACTPU;
           if the CV is present, the PU name will be used in the
           algorithm to search for a matching PU defined at the DLUS:

              * PU name - if the DLUR supplies a PU name and if it
                matches a predefined PU name, the search is over;
                otherwise,

              * IDBLK/IDNUM - if the DLUR supplies an IDBLK/IDNUM and it
                matches a predefined IDBLK/IDNUM, the search is over
                (note that the PU names may not match - the DLUR will
                accept the DLUS-provided name); otherwise,

              * CP name - if the DLUR supplies a CP name and it matches
                a predefined CP name, the search is over (note that the
                PU names may not match - the DLUR will accept the
                DLUS-provided name); otherwise,

              * user exit - if an exit exists, a dynamic PU will be
                created (note that the PU names may not match - the
                DLUR will accept the DLUS-provided name); otherwise,
                the search will fail

                  - if the DLUS detects a name conflict,

                     *  if a duplicate PU name is detected, the DLUS
                        will reject the REQACTPU with

                          X'0888 0016'   The DLUR-specified network
                                         name is known, but is a
                                         duplicate resource

                     *  if a NETID mismatch is detected, the DLUS will
                        reject the REQACTPU with

                          X'0891 000A'   Invalid Network ID: the
                                         network ID in the Network Name
                                         control vector does not match
                                         the network ID of the target
                                         resource of the REQACTPU.

                  - if the PU name is unacceptable to the DLUS, it will
                    reject the REQACTPU with

                      X'080A 000F'   The request was rejected because of
                                     constraints or policies specific to
                                     the receiving DLUS.  The request
                                     should not be retried.

         - if the DLUS cannot find a matching defined PU and a
           dynamic PU is created, it can use the PU name included
           in the REQACTPU

         - if the DLUR receives a PU name on ACTPU different from the
           name sent with the REQACTPU, it will accept the
           DLUS-provided PU name; this can occur, for example, when the
           DLUS does not recognize the PU name sent with the REQACTPU;
           if other information is present, it can find a match based
           on IDBLK/IDNUM or CP name and return the name of the
           matching predefined PU

         - when a DLUR receives an ACTPU, the search order to find the
           correct PU is as follows:

              * PU name - this name does not have to match a
                DLUR-defined name for the same PU, and the DLUS-provided
                PU name will be accepted

              * CP name and/or IDBLK/IDNUM - whatever is received must
                match its corresponding definitions at the DLUR

      This item was documented in abs8294.txt and arch8294d.psbin

** 13) clarified DLUR EN tail vector registration processing

      Questions from DLUR implementers concerning DLUR EN tail vector
      registration procedures have pointed out a need to specify in the
      DLUR architecture document the algorithm for DLUR to use to decide
      which session (CP-CP or CP-SVR) session to use to send TDUs.  The
      algorithm needs to take into account:

        * session outages
        * preferred sessions activating after not-so-preferred sessions
        * initial and subsequent TGV registration
        * adjacent and non-adjacent DLUR/DLUS pairs

      It turns out that VTAM handles the TDUs the same whether they are
      sent over the CP-CP session or the CP-SVR pipe.  Therefore, this
      item will also optionally allow the adjacent DLUR to not use the
      CP-CP session and only use the CP-SVR pipe for tail vector
      registration (an option that many implementers have requested).

      This clarification includes updating the "DLUR EN Tail Vector
      Registration" section of the DLUR Architecture Reference to
      include the following algorithm for DLUR to follow to determine
      which session (CP-CP or CP-SVR) to use to send TDUs:

          1) at initial TGV registration,

               a) if the DLUR and the DLUS are adjacent, then the DLUR
                  may optionally send the TDUs over the CP-CP session
                  between the two nodes

               b) otherwise the TDUs will be sent over the CP-SVR pipe
                  to the DLUS node

          2) if the CP-SVR pipe is selected for initial registration:

               a) continue to use it for subsequent TGV registration
                  even if a CP-CP session between adjacent DLUR and
                  DLUS is activated later

               b) if the CP-SVR pipe fails, once the pipe is reactivated
                  (to either the same or a different DLUS), return to
                  step 1) and send all tail vectors

          3) if the CP-CP session is selected for initial registration:

               a) continue to use it for subsequent TGV registration

               b) if the CP-CP session fails, return to step 1) and
                  send all tail vectors

               c) if the CP-SVR pipe fails, once the pipe is reactivated
                  (to either the same or a different DLUS), return to
                  step 1) and send all tail vectors

      This item was documented in abs8296.txt and arch8296d.psbin

** 14) added support for signaling information definition at DLUR

      DLUR signaling information is currently defined via DLCADDR at the
      DLUS.  While some users prefer centralized (at DLUS) signaling
      information definition, there are others who prefer distributed
      (at DLUR) definition.  The DLUS does not require DLCADDR to be
      defined, so some or all of the information currently defined via
      DLCADDR at the DLUS should be allowed to be optionally sysdefed
      at the DLUR instead.

         * DLUR-initiated SSCP-PU activation
           ---------------------------------
           It appears that the DLUR already has the signaling
           information it needs when it builds REQACTPU.  If this is
           true, it shouldn't be necessary to:

              - define the same signaling information at the DLUS
              - send the same signaling information with ACTPU

           DLUR can send the signaling information with REQACTPU; the
           DLUS uses it for:

              - network management
              - CSX user exit for connection verification and accounting
              - internal PU correlation

         * DLUS-initiated SSCP-PU activation
           ---------------------------------
           If the DLUS has only partial signaling information defined,
           it does not affect:

              - network management
              - CSX user exit for connection verification and accounting
              - PU correlation

           Some, if not all, of the signaling information defined at the
           DLUS via DLCADDR could be optionally defined at the DLUR.

      The solution is to update the DLUR architecture reference
      as follows:

      Signaling Information - This parameter will identify the
      DLUR-to-PU connectivity.  This information must be coordinated
      between the DLUR and DLUS nodes:

         1) it can be defined completely at the DLUR - in this case some
            or all of the information can optionally be sent to the
            DLUS to be used for network management, input into the
            Configuration Services XID exit for connection verification
            and accounting, and PU correlation

         2) it can be defined completely at the DLUS - in this case all
            of the information will be sent to the DLUR on the ACTPU

         3) it can be defined partially at the DLUS and partially at
            the DLUR - in this case the DLUR can optionally send the
            DLUR-defined signaling information (for the reasons
            described above) while the DLUS-defined signaling
            information will be sent on the ACTPU

               - if upon receipt of the ACTPU, the DLUR determines it
                 has incomplete signaling information, it can optionally
                 proceed with the activation (using defaults) or it can
                 fail the activation with sense code X'086D 46mm',
                 where mm = the subfield key of a missing subfield.

               - if upon receipt of the ACTPU, the DLUR determines it
                 has the same signaling information subfield from both
                 the DLUR and DLUS, but the subfields have different
                 values, it will optionally:

                     * allow the DLUS values to prevail

                     * allow the DLUR values to prevail

                     * reject the ACTPU with sense code X'0877 0059'

               - if upon receipt of the REQACTPU, the DLUS determines
                 it has the same signaling information subfield from
                 both the DLUR and DLUS, but the subfields have
                 different values, it can optionally reject the
                 REQACTPU with sense code X'0877 005A'.

      This item was documented in abs8326.txt and arch8326d.psbin

** 15) added APPN FR PVC signaling information formats for DLUR

      As a result of the frame relay boundary access node (BAN)
      capabilities, products have requested including BAN connections
      between a DLUR and a downstream LAN-attached node.  The DLUR DLC
      Signaling Information TG Descriptor Subfield formats for frame
      relay PVCs have already been defined in the architecture.  All
      that remains to accommodate the FR BAN function is to add a
      subfield (X'96') containing the destination MAC address.

      This item was documented in arch8318d.psbin

** 16) added DLUR/S processing for encapsulated FID2 segments on
       CP-SVR pipe to DLUS

      A requirement has been submitted by VTAM and CM/2 to support
      segmented FID2 PIUs for encapsulated data transmissions received
      over the CPSVRMGR pipe from the DLUR.  There are some messages
      which are encapsulated and sent on the CP-SVR pipe from the DLUR
      to the DLUS, for example, NMVTs, which can be received by the
      DLUR from the DLUR-serviced device in segments.  Currently the
      DLUS does not expect to receive encapsulated segments, only
      encapsulated whole messages.  If a DLUR could encapsulate these
      segments, they could be sent without first being reassembled at
      the DLUR.

      The solution will allow the DLUR to encapsulate FID2 PIU segments
      in separate GDS X'1500's.  The only PIUs which can be sent
      segmented are FMD requests, FMD responses with QRI=1, and
      non-expedited DFC requests.  The segments will be reassembled at
      the DLUS.

      This item was documented in abs8321.txt and arch8321d.psbin

** 17) added DLUR segmentation support for short RSP(BIND) LUs

      Several products have raised concerns with the current DLUR WBRI
      processing for SLUs sending short RSP(BIND)s.  The DLUR and NCP
      both assume that such a SLU cannot handle segments (indicating
      WBRI set on).  However, when a PIU too large to be sent on the
      downstream link to the SLU is received, the DLUR will UNBIND the
      LU-LU session while the NCP will segment the message.

      This is a mismatch of function putting the DLUR at a disadvantage
      (even though it is doing the right thing).  For easier migration,
      the DLUR should follow the NCP's procedure.

      The solution is based on the realizations that:

        1) For APPN, WBRI has meaning for a hop, not the LU itself.
           When DLUR sets WBRI, it is indicating its own ability to
           handle segments from the upstream hop, not the SLU's
           ability.

        2) When a SLU returns a short +RSP(BIND) for a BIND request
           whose max RU size exceeded the downstream link capability,
           one can infer an implied capability to accept segments at
           the SLU.  Detecting those conditions, a DLUR BF could send
           segments to the SLU.

        3) Some DLURs with memory constraints may be concerned that the
           whole PIU sent from the PLU may exceed their capacity to
           receive it.  With segmentation on the downstream link now
           allowed, the DLUR could set WBRI off and accept segments from
           the PLU but not reassemble them before sending anything to
           the SLU.  The DLUR could pass the segments on to the SLU, or
           if the PLU segment was too large for the link, break the PLU
           segment up into multiple segments and send them to the SLU.

      Therefore, the DLUR WBRI processing will be updated with:

         * if WBRI is reserved, act as if DLUR received WBRI=0; if
           segments are received from the PLU, the DLUR can either:

             - reassemble the segments and attempt to send the whole
               message to the SLU (only if the DLUR supports segment
               reassembly); if the reassembled message is too
               large, the DLUR can segment the message and send the
               segments to the SLU

             - attempt to send the segments received from the PLU to
               the SLU; if a segment is too large, the DLUR can segment
               the PLU segment and send the new segments to the SLU

      This item was documented in abs8322.txt and arch8322d.psbin

** 18) fixed incorrect definition of DLUR ACTPU Indicator

      The explanation of the DLUR ACTPU Indicator in section 13.1.8 of
      the external DLUR architecture reference is incorrect.  It
      currently states this indicator is only used by a DLUR node which
      has set the ACTPU Suppression Indicator; it should state (as do
      sections 6.2.3.3 and C.1.1) that the indicator is only used by a
      DLUR node which has reset the ACTPU Suppression Indicator.

      This item was documented in abs8333.txt and arch8333d.psbin

Ed Tremblay